微服务划分与安全
Business Capacity职能划分
对于对业务模型不了熟悉的情况选择, 这种比较简单, 由公司不同部分进行划分的, 例如客服是提供客户服务的职能, 财务部们提供财务的相关服务
Bounded Context 界限上下文
界限上下文是DDD中用来划分不同业务边界的元素, 是一种工程思路和架构思路. DDD对架构拆分, 软件工程组织有帮助 DDD用来划分不同业务边界的一种方式, 业务边界指的是解决不同业务问题的问题域和对应的解决方案域, 为了解决某种类型的业务问题, 贴近领域知识, 也就是业务, 解决一类业务场景, 解决某类业务场景, 它一定是贴近领域的一些知识, 也就是贴近业务维度的一个思考的划分方式 示例: 当用户需要投稿时: 会经过稿件API和视频API, 如果是按照职能划分, 那一定是稿件部分和视频部门两个来做, 如果是DDD, 就可以抽象为一个投稿服务, 对这个领域业务进行划分
CQRS模式
将应用划分为两部分, 一个查询端和变更端, 例如稿件服务, 流程是: 这类服务通常都是有大量的变更, 但是用户只想知道最终结果, 但是这里查询和变更强耦合的话, 后续审核等越来越复杂时,判断的变量越来越多, 代码就更加耦合, 就把查询和变更进行拆分, 把业务划分为: 稿件审核负责业务变更, 投稿结果负责业务查询
graph TB
稿件-->创作
稿件-->|模拟成MySQL的slave,canal|MySQLA -->|canal| Kafka
Kafka -->|订阅| 稿件job -->|消费并写入| MySQLB
External -->|gRPC| 稿件结果-->MySQLB
微服务安全
外网信息安全强调信息安全, 内网的安全是认证和授权, 一般在内网的服务都是要做身份认证和授权